refactor!: KeyringController always derives encryption key
#7128
+378
−163
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
mikesposito
force-pushed
the
mikesposito/keyring-controller/never-use-password
branch
from
8f04566 to
ad1ae0d
Compare
4 tasks
| state.encryptionSalt = updatedState.encryptionSalt; | ||
| } | ||
| state.encryptionKey = encryptionKey; | ||
| state.encryptionSalt = parsedEncryptedVault.salt; |
Contributor
There was a problem hiding this comment.
I think there is a potential bug here:
Above you set
this.#setEncryptionKey(
credentials.encryptionKey,
credentials.encryptionSalt || parsedEncryptedVault.salt,
);but here you set
state.encryptionSalt = parsedEncryptedVault.salt;Shouldn't this be:
state.encryptionSalt = this.#encryptionKey.salt;
Member
Author
There was a problem hiding this comment.
As we are decrypting the vault here, the existing vault salt and this.#encryptionKey.salt should always be the same, even when the salt is undefined, right?
Member
There was a problem hiding this comment.
Yeah, we have a check to ensure they are the same in #setEncryptionKey. See where we throw the KeyringControllerError.ExpiredCredentials error.
Though... it is a bit confusing that the guarantee about these being the same is in a different function 🤔. Perhaps it would be simplest to use this.#encryptionKey.salt; just so the reader doesn't need to understand where it was validated?
Potentially a slight readability improvement here, but I don't think it's a bug
Member
Author
There was a problem hiding this comment.
That makes sense. I was being conservative on what was there before, but I agree that using this.#encryptionKey.salt is clearer, and should be equivalent. Done in c59a9c1
Base automatically changed from
mikesposito/keyring-controller/remove-cache-encryption-key
to
main
November 12, 2025 14:33
4 tasks
mikesposito
force-pushed
the
mikesposito/keyring-controller/never-use-password
branch
from
5f8200d to
54baecf
Compare
the package was also updated to ^6.0.0
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Gudahtt
reviewed
Nov 12, 2025
Member
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
Draft
7 tasks
lwin-kyaw
approved these changes
Nov 13, 2025
mikesposito
deleted the
mikesposito/keyring-controller/never-use-password
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
This PR extracts the second and final set of changes from #5963, which refactors the
KeyringControllerto always derive the encryption key from the password, rather than storing it in memory.This change allows to simplify
#unlockKeyringsand#updateVaultmethods, after the removeal of all the logic and tests related tocacheEncryptionKey. This also allows to removethis.#password, that has been replaced bythis.#encryptionKey.The
this.#encryptionKeyassignment logic has been moved to two new internal methods with these specific responsibilities:#deriveEncryptionKey(string): Derives the encryption key from the password, to be used during password login and password change.#useEncryptionKey(string, string): Uses an existing encryption key to be used directly, to be used bysubmitEncryptionKeymainly.Package previews from this branch are tested on clients with these PRs:
@metamask/{keyring,seedless-onboarding}-controllermetamask-extension#37454@metamask/keyring-controllermetamask-mobile#22240References
Checklist
Note
KeyringController now derives and uses an exportable encryption key (with salt) instead of storing the password, updates method flows and error handling, and requires encryptors to implement exportKey/keyFromPassword/generateSalt; dependencies and tests updated accordingly.
encryptionKey+salt; removes in-memory password usage and persists vault viaencryptWithKey.submitPassword,submitEncryptionKey,changePassword, and vault upgrades now use derived/exported keys.#deriveAndSetEncryptionKeyand#setEncryptionKey; updates rollback/persist logic to track encryption credentials.WrongEncryptionKeyTypeerror; improves validation and error paths (e.g., missing/expired credentials, vault shape).Encryptorinterface (BREAKING): requiresexportKey,keyFromPassword, andgenerateSalt.encryptormust implementexportKey,keyFromPassword,generateSalt.@metamask/browser-passworderto^6.0.0in affected packages.Written by Cursor Bugbot for commit 71fc196. This will update automatically on new commits. Configure here.